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PROTOTYPE  PROGRAMMING  ENVIRONMENT 

PART  VI 


Bruce  J.  MacLennan* 

Computer  Science  Department 

Naval  Postgraduate  School 

Monterey,  CA  93943 


Abstract: 

This  is  the  last  report  of  a  series  exploring  the  use  of  the  VI  programming  notation  to  prototype  a  program- 
ming environment.  This  environment  includes  an  interpreter,  unparser,  syntax  directed  editor,  command 
interpreter,  debugger  and  code  generator,  and  supports  programming  in  a  small  applicative  language.  This 
report  presents  a  universal  (i.e.,  table-driven)  syntax  directed  editor  and  unparser,  which  requires  only  53 
rules  to  express.    A  running  implementation  of  these  ideas  is  listed  in  the  appendices. 


I.    Goals 

A.   Introduction 

Our  goal  in  this  series  of  reportsf  [MacLennan85b,  MacLennan85c,  MacLennan86a,  MacLennan86b, 
MacLennan86c]  is  to  explore  in  the  context  of  a  very  simple  language  the  use  of  the  f2  programming  nota- 
tion [MacLennan83,  MacLennan85a]  to  implement  some  of  the  tools  that  constitute  a  programming 
environment. 

In  Part  VI  we  address  the  following  problem:  Each  extension  to  the  language  has  required  new  rules  to 
be  added  to  the  unparser  and  editor.  However,  the  new  rules  have  been  very  similar  in  every  case.  There- 
fore, our  goal  will  be  to  make  the  unparser  and  editor  table- driven  (like  a  table-driven  parser)  so  that  only 
the  tables  need  be  changed  when  the  language  is  extended. 

What  information  needs  to  be  provided  to  permit  table-driven  syntax-directed  editing?  We  will  cer- 
tainly need  the  sort  of  syntactic  information  normally  provided  in  a  BNF  grammar.    This  tells  how  pro- 
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gram  trees  are  unparsed  onto  the  display.  An  example  of  the  sort  of  information  required  is  shown  in 
Table  1,  which  contains  the  grammar  for  our  sample  language;  we  will  take  it  as  typical  of  the  kinds  of 
grammars  we  would  like  to  handle. 

TABLE  1.    Grammar  for  Sample  Language 


<  program  > 

=  <expr> 

<expr> 

=  <arex>  <rel>  <arex> 

<arex> 

<rel> 

=  <|   >|   <|   £|   =|   * 

<arex> 

=  <arex>  {  +  |  —  }  <term> 

<term> 

<term> 

=  <term>  {  x  |  +  }  <factor> 

|  <factor> 

<factor> 

=  <number> 

|  <var> 

<var>  <factor> 

|  (  <expr>  ) 

|   (if  <expr> 

then  <expr> 

else  <expr>  ) 

[let    <var>  =  <expr> 

<expr>  ] 

[func    <var>  <var>  =  <expr> 

<expr>  ] 

B.   Editing  Commands 

If  we  are  to  automatically  generate  a  syntax-directed  editor  then  we  also  need  to  know  the  selector-keys 
associated  with  the  various  language  constructs.  Table  2  shows  an  example  of  this  information  for  the  case 
of  the  sample  language. 

These  selector  commands  are  language- dependent,  i.e.,  they  depend  on  the  kinds  of  constructs  included 
in  the  language  (although  we  would  hope  for  some  consistency  in  their  choice).  A  number  of  other  com- 
mands are  language- independent:  they  are  the  same  for  all  languages.  For  example,  we  have  the  naviga- 
tion commands: 


TABLE  2.    Selector  Keys  for  Sample  Language 


IK 

— » 

<arex>  =  <arex> 

n 

- 

<arex>  #  <arex> 

< 

-» 

<arex>  <  <arex> 

> 

-» 

<arex>  >  <arex> 

[ 

- 

<arex>  ^  <arex> 

1 

-* 

<arex>  ^  <arex> 

+ 

— ♦ 

<arex>  +  <term> 

- 

-► 

<arex>  —  <term> 

* 

— ► 

<term>  x  <factor> 

1 

— ► 

<term>  -J-  <factor> 

# 

•* 

<number> 

- 

<var> 

c 

- 

<var>  <factor> 

( 

— ► 

(  <expr>  ) 

i 

- 

(if  <expr>  then  <expr>  else  <expr>  ) 

1 

- 

[let  <var>  =  <expr>  <expr>  ] 

f 

[fane  <var>  <var>  =  <expr>  <expr>  ] 

in,  out,  next,  prev,  root 

We  also  have  the  delete  command,  which  works  on  any  language  construct  (the  insertion  commands  are 
language-dependent;  they  are  the  selector  keys).  Finally,  we  will  postulate  a  single  mechanism  for  entering 
strings  of  characters,  whether  for  identifiers,  literal  constants,  comments,  or  whatever: 

_cic2cs  •  •  •  cn@ 

The  '_'  key  (typically  the  spacebar)  initiates  the  accumulation  of  characters,  and  the  '@'  key  (typically  the 
carriage  return)  completes  the  accumulation  and  enters  the  string  into  the  structure. 

C.   Example  Session 

Suppose  we  wish  to  enter  the  following  program: 

[let  K  -  16 
[fane  fac  n  = 
(if  n  =  0 
then  1 

else  n  x  fac  (n  —  1)  ) 
fac  (K  -r  2)  ]  ] 

When  the  system  is  entered  we  will  be  prompted  for  a  program: 
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<program> 

Typing  the  T  selector  key  calls  for  the  creation  of  a  let  block1: 

1 
[let  <var>  =  <expr> 
<expr>  ] 

The  bound  variable  is  entered,  and  we  move  to  the  bound  value: 

_K@  next 
[let  K  =  <expr> 
<expr>  ] 

The  literal  constant  '16'  is  entered,  and  we  move  to  the  body: 

#_16@  next 
[let  K  -  16 

<expr>  ] 

The  T  key  calls  for  the  creation  of  a  function  definition  block: 

f 
[let  K  =  16 
[func  <var>  <var>  =  <expr> 
<expr>  ] 

The  function  name  is  entered: 

_fac@  next 

[func  fac  <var>  =  <expr> 
<expr>  ] 

The  formal  parameter  is  entered: 

_n@  next 

[func  fac  n  =  <expr> 


1.    In  each  case  we  show  the  command  typed,  followed  by  the  resulting  display. 
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<expr>  ] 

An  if  expression  is  requested: 

i 

[func  fac  n  = 
(if  <ezpr> 
then  <expr> 
else  <expr>  ) 
<expr>  ] 

For  the  expression  'n  =  0',  we  first  enter  the  operator: 
<arex>  =  <arex> 


Next  we  enter  the  variable  'n'  and  move  right: 


n@  next 


n  =  <arex> 


The  condition  is  completed  by  entering  the  number  '0': 

#_0@ 
n  =  0 

Moving  right  focuses  attention  on  the  consequent  of  the  conditional: 

next 

(if  n  =  0 
then  <expr> 
else  <expr>  ) 

The  literal  constant  '1'  is  entered  as  the  consequent  of  the  if: 

1 
The  next  component  is  the  alternate: 


next 

(ifn  =  0 
then  1 
else  <expr>  ) 

The  product  of  n  and  the  factorial  of  n— 1  is  entered  as  the  alternate.    First  we  request  a  product: 


<term>  x  <factor> 

We  enter  the  variable  'n'  and  move  right: 

n@  next 

n  x  < factor > 

The  'c'  key  requests  a  function  call: 

c 
n  x  <var>  <factor> 

We  enter  'fac'  and  move  right: 

fac@  next 

n  x  fac  <factor> 

For  the  argument  we  request  a  parenthesized  expression: 

( 

n  x  fac  (<expr>) 

Notice   that    the   closing   parenthesis   is   automatically   supplied,   so   there   is   no  possibility   of  misnested 
parentheses.    The  '  — '  key  requests  a  difference: 

n  x  fac  [<arez>  —  <term>) 
The  difference  is  completed  routinely: 
n@  next  #    1@ 
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n  x  fac  (n  —  1) 
Moving  to  the  next  component  brings  us  to  the  body  of  the  function  definition  block: 

next 

[let  K  =  16 
[func  fac  n  = 
(if... 
then  ... 
else  ...  ) 
<expr>  ] 

We  have  shown  the  components  of  the  conditional  as  '...',  representing  suppressed  detail,  although  on  a 
reasonably  sized  screen  the  entire  program  would  be  shown.  (This  suppression  of  detail  is  called  holo- 
phrasting  in  the  literature.)  The  body  of  the  function  definition  block  is  the  invocation  of  factorial  with 
k-=-2: 

c  _fac@  next  /  _K@  next  #_2@ 
fac  (K  -r  2) 

We  shift  our  focus  back  to  the  root,  where  we  see  the  completed  program: 

root 
[let  K  =  16 
[func  fac  n  = 
(if  n  =  0 
then  1 

else  n  x  fac  (n  —  1)  ) 
fac  (Kt2)][ 

D.    Transaction  Grammar 

How  might  we  express  concisely  the  connection  between  concrete  syntax,  abstract  syntax  and  editing 
commands?  We  will  use  a  translation  grammar  augmented  by  selector  keys,  which  we  call  a  transaction 
grammar.   There  are  a  variety  of  notations  for  transaction  grammars.    For  example: 


<arex>: 
+  -*    <arex>  +  <term> 

=>  Sum  (Left  =  <arex>,  Right  =  <term>) 

►    <arex>  —  <term> 

=*>  Dif  (Left  =  <arex>,  Right  =  <term>) 

else  <term> 

This  means  that  if  a  '  +  '  key  is  typed,  then  a  Sum  node  is  generated  (which  is  unparsed  '<arex>  + 
<term>').  The  else  clause  means  that  if  any  key  other  that  '  +  '  or  '  — '  is  typed  when  <arex>  is  expected, 
then  that  key  will  be  "forwarded"  to  the  <term>  rule.  For  example,  if  a  '/'  is  typed  when  an  <arex>  is 
expected,  it  will  be  passed  to  <term>,  where  it  will  generate  a  Quo  (quotient)  node. 

Note  we  have  made  some  changes  to  abstract  syntax:  instead  of  one  Appl  node  we  now  have  different 
nodes  for  the  different  operations  (Sum,  Dif,  etc.).    This  simplifies  unparsing. 

We  will  use  a  slightly  different  notation  for  transaction  grammars  that  is  more  compact,  since  it  merges 
the  analysis  and  synthesis  parts  of  the  rule.    For  example,  the  rule  for  <arex>  is: 

<arex> 
+  (Sum)  ->  Left:<arex>  +  Right:<term> 
-  (Dif)  ->  Left:<arex>  -  Right:<term> 
else  <factor> 

This  say  that  a  '+'  key  creates  a  Sum  node,  whose  Left  component  is  an  <arex>  and  whose  Right  com- 
ponent is  a  <term>.  Table  3  shows  most  of  the  transaction  grammar  for  the  sample  language;  only  rou- 
tine parts  have  been  omitted. 

II.    Requirements 

What  sort  of  tables  are  needed?  We  will  consider  the  data  structures  needed  to  support  language- 
independent  (A)  unparsing  and  (B)  syntax-directed  editing.  This  will  allow  us  to  define  the  necessary  rela- 
tions. 


TABLE  3.   Transaction  Grammar  for  Sample  Language 


<program>  = 

<expr> 

<expr>u 

=  (Eql)  -»  Left:<arex>  =  Right :<arex> 
n  (Neq)  -»  Left:<arex>  =  Right: <arex> 

else  <arex> 

<arex>: 

+  (Sum)  -*  Left:<arex>  +  Right:<term> 
-  (Dif)  -»  Left:<arex>  -  Right:<term> 
else  <term> 

<term>: 

*  (Prd)  -»  Left:<term>  x  Right: <factor> 
/  (Quo)  -»  Left:<term>  -f  Right:<factor> 
else  <  fact  or  > 

<factor>: 

#  (Con)  —  LitVal:<chars> 

c  (Call)  —■  Rator:<chars>  Rand:<factor> 

(  (Par)  —  (  Exp:<expr>  ) 

i  (ConEx)  -  %I%N  (if  Cond:<expr> 
%N  then  Conseq:<expr> 
%N  else  Alt:<expr>  )  %0 

1  (Block)  -  %I  [let  BndVar:<chars>  =  BndVal:<expr> 
%N  Body:<expr>  j  %0 

f  (FunDef)  —  %I  [fane  FunName:<chars>  FunFormal:<chars> 
%N  FunScope:<expr>  ]  %0 

=  FunBody:<expr> 

else  (Var)  ->  Ident:<chars> 

A.   Unparsing 
1.    Alternates 

For  each  syntactic  category,  e.g.,  <expr>,  we  must  be  able  to  select  an  image-template  based  on  the  kind 
of  node  (the  node  variant).    E.g. 

Block    =>    [let  -  = ] 

ConEx    =>    (if  —  then  —  else  —  ) 


These  are  called  alternates  of  the  syntactic  category. 


2.    Image-templates 

For  each  alternate,  we  need  an  image- template,  which  is  a  sequence  of  items.  Items  are  either  terminals  or 
nonterminals. 

a)  Terminals  are  strings  of  characters  and  formatting  commands  (e.g.,  tabs  and  newlines).    E.g., 

"%I%N(if  " 

b)  Nonterminals  must  specify: 

i.    An  associated  selector  relation,  e.g.,  Cond,  Conseq  or  Alt  for  ConEx  nodes. 

ii.    A  syntactic  category  determining  what  can  legally  occur  in  that  position,  e.g.,  <expr>  for  the  Cond 
part  of  a  ConEx.    This  is  needed  for: 

•  Prompting  for  the  required  category 

•  Determining  the  format  by  which  to  display  a  component 

c)  There  are  two  kinds  of  image  templates: 
i.    Simplex 

ii.     Complex 

i.    A  simplex  template  is  composed  of  a  single  nonterminal,  possibly  surrounded  by  terminal  items,  e.g. 

"("  <expr>  ")" 
It  does  not  break  a  node  into  its  components  for  unparsing,  but  relies  on  the  nonterminal's  rule  to  do  this. 

ii.  A  complex  template  breaks  a  node  into  its  components  and  unparses  each  component  according  to  a 
given  nonterminal.  These  unparsed  results  are  catenated  with  appropriate  terminals  between  and  around 
them,  e.g. 

"%I%N  (if"  Cond:<expr> 
"%N  then"  Conseq:<expr> 
"%N  else  Alt:<expr>  ")  %0" 
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S.   Display  Control 

We  will  also  need  a  means  for  displaying  the  context  of  the  current  node,  i.e.,  the  surrounding  tree  struc- 
ture. We  want  to  display  the  context  of  the  current  node,  but  without  zooming  in  or  out  too  frequently 
(which  would  confuse  the  user).  Furthermore,  we  want  to  suppress  sufficient  detail  so  that  the  displayed 
region  of  the  tree  will  fit  on  the  display  screen.  Therefore  we  define  parameters  for  controlling  the  display 
as  depicted  in  Figure  1. 


Display 


Depth 


Focus 


Figure  1.    Parameters  Controlling  Display 

'Display'  represents  the  region  of  the  tree  presented  on  the  screen.  Detail  below  the  'Depth'  level  is 
suppressed  so  that  the  displayed  region  will  fir  on  the  screen.  'Focus'  refers  to  the  current  node,  to  which 
commands  refer.  It  is  unparsed  in  a  distinctive  way  (typically,  in  inverse  video).  The  focus  can  be  shifted 
anywhere  within  the  displayed  area.  However,  if  the  focus  reaches  the  depth  limit,  then  the  display  zooms 
in  (i.e.,  the  Display  node  shifts  down).  If  the  focus  reaches  the  display  root,  then  the  display  zooms  out. 
This  policy  minimizes  movement  _pf  Display. 

B.    Syntax-Directed  Editing 

We  must  consider: 

1.  Creation  of  program  trees 

2.  Deletion  of  subtrees 

3.  Motion  within  the  program  tree 
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1.  Creation 

a.  We  need  to  be  able  to  select  a  node  kind  out  of  those  that  are  legal  at  a  given  position.  E.g.,  if  an 
<expr>  is  expected,  then  we  must  be  able  to  select  Var,  Appl,  ConEx,  etc.  Further,  we  must  specify  the 
command  key  associated  with  each  selection. 

b.  We  need  to  know  the  selector  relations,  so  that  undefined  components  can  be  created  when  a  node  is 
created.  E.g.,  when  a  ConEx  node  is  created,  we  need  to  link  it  to  new  undefined  nodes  by  the  Cond,  Con- 
seq  and  Alt  relations. 

c.  We  need  to  know  which  component  (i.e.,  selector  relation)  is  first  (i.e.,  leftmost  in  display  order)  so  that 
the  focus  can  be  shifted  there.  E.g.,  when  a  ConEx  node  is  created,  the  focus  should  be  shifted  to  its  Cond 
component. 

d.  We  need  to  know  the  next  component  (i.e.,  selector  relation)  in  display  order  so  that  focus  can  be 
shifted  to  the  right  as  each  component  is  completed.  E.g.,  when  the  Cond  of  a  ConEx  is  finished,  we  shift 
to  the  Conseq,  and  when  that  is  done  to  the  Alt. 

e.  We  need  to  be  able  to  "chain"  from  grammar  rule  to  grammar  rule.  E.g.,  Suppose  '  +  '  and  '— '  are  legal 
command  keys  for  <arex>,  and  'x'  and  '-£-'  are  legal  keys  for  <term>,  and  '('  and  '#'  are  legal  for  <fac- 
tor>.  Also  suppose  a  <factor>  is  a  legal  <term>  and  a  <term>  is  a  legal  <arex>.  Then,  typing  a  'x' 
where  an  <arex>  is  required  should  chain  to  the  <term>  rule,  and  typing  '#'  where  an  <arex>  is  required 
should  chain  to  the  <factor>  rule. 

2.  Deletion 

a.  We  need  to  know  the  syntactic  category  expected  after  a  deletion.    For  example,  when  a  Quo  node  is 
deleted  from  the  Conseq  component  of  a  ConEx,  the  user  should  be  prompted  for  <expr>. 

b.  We  need  to  know  all  selector  relations  for  a  node  kind,  so  that  all  its  components  can  be  deleted. 

3.  Motion 

a.    We  need  to  know  next  and  previous  nodes  in  display  order.    N.B.,  there  is  no  next  or  previous  inherent 
in  the  abstract  structure;  the  display  order  is  determined  by  the  concrete  syntax. 
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b.  We  need  to  know  first  node  in  display  order,  for  the  in  command. 

c.  We  need  to  be  able  to  get  to  the  parent  node,  for  the  out  command.    Note  that  there  is  no  one  selec- 
tor relation  that  links  a  node  to  its  parent. 

HI.   Outline  of  Relations 

Based  on  the  preceding  analysis  we  outline  the  relations  required  to  support  the  necessary  data  structures. 
The  requirements  supported  by  a  relation  are  listed  in  brackets  following  the  description  of  the  relation. 

A.  User  Interface 

The  relations  used  for  interfacing  to  the  user  are  similar  to  those  used  in  Parts  I  through  V. 

•  Command  (A,  c) 

Agent  A  issues  command  c. 

Note  that  'Command'  has  been  changed  from  a  one-place  to  a  two-place  relation;  this  simplifies  com- 
mand synchronization  since  it  allows  'Command'  to  be  called  as  a  procedure,  'Command  {c}'. 

•  Argument  («) 

s  is  the  argument  string. 

•  Error  (A,  s) 

Agent  A  reports  error  message  s. 

As  usual  we  assume  the  existence  of  the  'display'  procedure. 

B.  Kinds  of  Templates 

Whenever  we  refer  to  a  template  T  we  mean  the  first  item  in  the  chain  of  items  constituting  the  template. 

.      Template  (  T,   V,  N) 

T  is  the  image  template  for  node  variant  V  under  nonterminal  N.    [Al] 

•  DefaultTemplate  ( T,  N) 

T  is  the  default  template  for  nonterminal  N.    [Al,  Ble] 

•  Complex  ( T) 

T  is  a  complex  template.    [A2c] 
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Thus,  the  data  structures  for  a  nonterminal  such  as  <arex>  look  like  this: 


Template  (•,  'Sum',  •  ) 


Template  (•,  'Dif ,  • 


DefaultTemplate  (•,  •  ) 


•  <arex> 


->- template  for  "<term>" 


Figure  2.   Data  Structures  Representing  the  Nonterminal  <arex> 

Nonterminallmage  is  described  in  D,  below. 

C.  Parts  of  Templates 

These  relations  and  those  in  the  next  section  represent  the  parts  of  templates.    In  this  section  we  describe 
the  relations  that  represent  the  sequencing  of  items  and  the  representation  of  terminal  items. 

•  Nextltem  (J,  I,  N) 

J  is  the  next  item  after  /  in  an  image  template  for  nonterminal  N.    [A2j 

•  Terminal  (/) 

/  is  a  terminal  item  [A2a,  A2b] 

•  Terminallmage  (5,  /) 

S  is  the  image  of  terminal  item  I.    [A2a] 

D.  Nonterminals 

These  relations  represent  nonterminals,  including  the  node  components  to  which  they  correspond,  their 
syntactic  category,  and  the  string  that  represents  them  to  the  user. 
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•  Selector  (R,  I,  T) 

Et  is  the  selector  for  nonterminal  item  /  in  template  T.    [A2bi,  B2a] 

•  Category  (M,  I,  T) 

M  is  the  syntactic  category  of  nonterminal  item  /  in  template  T.    [A2bii] 

I     •      Nonterminallmage  (5,  N) 

i  5  is  the  image  of  nonterminal  N.    [A2bii] 

j 

{ 

The  following  figure  displays  the  data  structures  corresponding  to  the  template: 

1 

I 

Left:<arex>  '  +  '  Right:<term> 


Complex 


Selector      Category 


Terminal 


Terminallmage 


Selector      Category 


'Left' 


•  <arex> 


+ 


'Right' 


•  <term> 


Figure  3.    Data  Structures  for  the  Template:    Left:<arex>  '  +  '  Right:<arex> 


Note   that   for  clarity   we   have   omitted   from   the  diagram   the   third   fields   of  Nextltem,    Selector   and 
Category. 

E.   Display  Control 

These  relations  control  the  region  of  the  program  displayed  on  the  screen  and  control  the  suppression  of 
low-level  detail. 

•      DisplayRoot  (E) 

E  is  the  display  root.    [A3] 

This  relation  determines  the  region  of  the  tree  displayed  on  the  screen.    It  is  the  node  at  which  unpars- 

ing  begins. 
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•  CurrentNode  {E) 

E  is  the  current  node.    [A3] 

This  relation  determines  the  node  that  is  the  object  of  all  editor  commands  (i.e.,  the  focus  of  editing). 

•  DepthLimit  (d) 

d  is  the  depth  limit.    [A3] 

This  parameter  determines  the  depth  beyond  which  detail  is  suppressed. 

•  CurrentDepth  (/) 

/  is  the  depth  of  current  node.    [A3] 

This  is  used  to  determine  when  the  depth  limit  is  exceeded. 

•  AssumedTemplate  (  T,  V) 

T  is  assumed  template  for  node  type  V.    [A3,  B2a] 

This  is  used  to  determine  the  template  by  which  to  unparse  the  display  root. 

These  parameters  are  described  in  more  detail  later. 

F.   Variant  Selection 

The  following  relations  are  used  for  identifying  language-dependent  creation  keys,  forwarding  them  from 
rule  to  rule,  and  associating  them  with  node  variants. 

•  ExecutiveCommand  (k) 

Key  k  is  an  executive  command.    [Bla] 

This  is  used  for  discriminating  between  the  language-independent  "executive  command  keys"  and  the 

language-dependent  selector  keys. 

.      VariantKey  (Jfc,  V,  N) 

Key  k  selects  variant  V  of  nonterminal  N.    [Bla] 

For  example,  '  +  '  selects  variant  'Sum'  of  <arex>,  and  '  — '  selects  variant  'DiF  of  <arex>. 

.     DefaultNT  {N,  M) 

Nonterminal  N  is  the  default  alternative  nonterminal  M.    [Ble] 
For  example,  <term>  is  the  default  nonterminal  for  <arex>. 
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G.   Node  Format 

These  relations  specify  the  left-to-right  (in  display  order)  relationship  among  the  selectors  of  a  node.  For 
example,  in  the  template 

'%I%N  (if  Cond:<expr> 
'%N  then  '  Conseq:<expr> 
'%N  else  '  Alt:<expr>  '  )%0' 

the  defined  order  of  selectors  is  (Cond,  Conseq,  Alt).  Note  that  we  might  easily  have  a  diiferent  template 
that  displays  the  components  in  a  different  order: 

'%I%N'  Conseq:<expr>  ',  if  Cond:<expr> 
'%N'  Alt:<expr>  ',  otherwise  '%0%N' 

This  template  defines  the  order  (Conseq,  Cond,  Alt).    The  relations  describing  selector  order  are: 

•  FirstSelector  (R,  T) 

R  is  first  selector  for  template  T.    [Bib,  Blc,  B2b,  B3bj 

For  example,  "Cond"  is  the  first  selector  for  the  template  for  conditional  expressions. 

•  NextSelector  (S,  R,  T) 

S  is  next  selector  after  R  in  template  T.    [Bib,  B2b,  B3a,  Blc] 

For  example,  "Conseq"  is  the  selector  after  "Cond"  in  the  conditional  expression  template. 

•  LastSelector  (R,  T) 

R  is  the  last  selector  for  template  T.    [Bib,  B2b,  B3a,  Blc] 

For  example,  "Alt"  is  the  last  selector  in  the  conditional  expression  template. 

H.   Node  Structure 

The  following  relations  define  the  actual  format  of  nodes.  This  is  a  difference  from  previous  reports  in  this 
series.  Rather,  than  using  individual  predicates  to  tag  each  node  type,  Con  (E),  Block  (E),  etc.,  we  now 
use  a  single  Type  relation  to  attach  the  type.  Hence  we  have  Type  ("Con",  E),  Type  ("Block",  E),  etc. 
(the  tag  is  simply  a  character  string).  Similarly,  instead  of  representing  node  components  by  a  number  of 
specialized  relations,  LitVal  ( V,  E),  BndVar  (N,  E),  etc.,  we  now  use  a  single  Component  relation,  so  we 
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have  Component  (V,  "LitVal",  E),  Component  (N,  "BndVar",  E),  etc.  Hence  component  relations  are 
simply  strings. 

.     Type  (7,  E) 

V  is  the  type  of  node  E.    [Al,  Bl,  B3bj 

•     Component  (X,  R,  Y) 

X  is  the  R  component  of  Y.    [B2a,  B3c] 

This  completes  the  description  of  the  principal  relations  used  in  the  table-driven  syntax-directed  editor, 
viz.,  those  relations  that  define  the  tables.  There  will  of  course  be  a  number  of  active  relations  used  to  con- 
trol the  activities  of  the  editor;  these  will  be  introduced  as  they  are  needed. 

IV.    Rules  for  the  Table-Driven  Syntax-Directed  Editor 

In  this  section  we  present  most  of  the  53  rules  required  to  implement  the  editor  (the  complete  system  is 
listed  in  Appendix  A).  Many  of  the  rules  are  largely  self  explanatory,  so  they  are  presented  with  minimal 
commentary. 

A.   Focus  Movement 

These  commands  shift  the  focus  under  control  of  the  template  and  node  description.  They  all  make  use  of 
the  procedure  'SetCurrentNode',  which  shifts  the  focus  and  in  addition  determines  if  this  focus  movement 
requires  the  display  root  to  be  moved. 

1.    in  Command 

For  an  in  command,  we  follow  the  branch  for  the  first  selector  for  the  template  associated  with  the  focus's 
node  type: 

*Command  (return,  in),  CurrentNode  (E),  Type  (  V,  E),  AssumedTemplate  ( T,   V), 
FirstSelector  (R,  T),  Component  (X,  R,  E) 
=>  {SetCurrentNode  {X};  Command  (return,  display)}. 

The  in  command,  like  all  navigation  commands,  issues  the  display  command,  which  refreshes  the  screen. 
We  use  ';'  to  indicate  sequential  action,  since  we  want  the  focus  to  be  shifted  before  the  display  is 
refreshed. 
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Also  note  that  by  passing  'return'  to  the  Command  procedure  in  the  effect  part  of  the  rule  we  have 
made  Command  tail-recursive.  The  effect  part  could  have  been  written  recursively,  but  it  would  be  less 
efficient: 

•  •  •     =*    {SetCurrentNode  {X};    Command  {display};    return  (Nil)}. 

Error  conditions  can  be  handled  by  an  else  rule: 

else  *Command  (return,  in) 

=>  Error  (return,  "No  inner  component."). 

We  assume  'Error'  is  a  procedure  that  takes  appropriate  error  reporting  action.  In  general  we  omit  show- 
ing the  error  handling  rules,  since  they  are  routine. 

2.    out  Command 

The  out  command  is  very  simple;    we  move  to  the  parent  of  the  current  focus: 

*Command  (return,  out),  CurrentNode  (X),  Component  (X, ~—,~E) 
=>  {SetCurrentNode  {E};  Command  (return,  display)}. 

In  effect  the  rules  says,  "If  the  current  node  is  some  component  of  another  node,  then  move  to  that  other 
node." 

S.    next  Command  (next  on  same  level) 

For  then  next  command  we  determine  the  selector  corresponding  to  the  current  node  and,  via  the  assumed 
template  for  the  parent  node  type,  find  the  selector  that  follows  the  current  one  in  that  template.  This 
allows  selecting  the  new  current  node. 

*Command  (return,  next),  CurrentNode  (X),  Component  (X,  R,  E),  Type  ( V,  E), 
AssumedTemplate  ( T,  V),  NextSelector  (5,  R,  T),  Component  (  Y,  5,  E) 

=>  {SetCurrentNode  {Y};  Command  (return,  display)}. 
4-    next  Command  (next  on  level  above) 

If  there  is  not  a  next  selector  at  the  current  level  in  the  tree,  then  we  shift  the  focus  to  the  parent  of  the 
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current  node  and  reissue  the  next  command: 

*Command  (return,  next),  CurrentNode  (X),  Component  (X,  R,  E),  Type  (V,  E), 
AssumedTemplate  ( T,  V),  — >NextSelector  (— ,  R,  T) 

=>  {SetCurrentNode  {E};  Command  (return,  next)}. 

Thus,  when  we  hit  the  next  key,  we  will  continue  zooming  out  until  either  we  reach  a  level  where  there  is 
a  next  component,  or  we  reach  the  root.    The  prev  command  is  exactly  analogous. 

B.   Focus  Motion 

1.  Simple  Version 

In  the  simplest  definition  of  the  SetCurrentNode  procedure  simply  moves  the  focus: 

*SetCurrentNode  (return,  X),  *CurrentNode  (E) 
=>  CurrentNode  (X),  return  (Nil). 

The  reason   we  have  defined   SetCurrentNode  is  to  permit   a  more  complicated  version   that  shifts  the 
DisplayRoot  if  necessary. 

2.  Display  Parameters 

To  understand  the  operation  of  SetCurrentNode  it   is  necessary  to  understand   the  role  of  the  various 
display  parameters  (see  Figure  4). 


DisplayRoot 


pthLimit 


CurrentNode 


Figure  4.    Display  Parameters 
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The  parameters  are  as  described  before  (Figure  1)  except  that  CurrentDepth  records  the  current  depth  at 
which  unparsing  is  taking  place.    When  this  exceeds  DepthLimit,  further  unparsing  is  suppressed. 

3.    Upward  Motion:  Shift  Needed 

When  an  attempt  is  made  to  shift  the  focus  to  the  parent  of  the  current  display  root,  then  we  are  moving 
out  of  the  displayed  region.  Therefore,  the  display  root  is  moved  to  the  parent  of  the  new  focus.  The 
result  is  that  the  display  gradually  "zooms  out"  as  the  focus  is  shifted  up  the  tree.  This  zooming  may  be 
too  gradual  when  one  is  moving  rapidly  up  the  tree.  A  more  complicated  rule  would  locate  the  new  root 
several  above  the  new  focus,  so  that  it  wouldn't  have  to  shift  so  often. 

*SetCurrentNode  (return,  E),  *CurrentNode  (X),  Component  (X,  — ,  E), 
*DisplayRoot  (X),  *CurrentDepth  (— ),  Component  (E,  — ,  D) 

=>  DisplayRoot  (D),  CurrentNode  (E),  CurrentDepth  (1),  return  (Nil). 
4-    Upward  Motion:  No  Shift  Needed 

When  we  haven't  reached  the  root,  we  simply  set  the  new  focus. 

else  *SetCurrentNode  (return,  E),  *CurrentNode  (X),  Component  (X,  — ,  E),  *CurrentDepth  (/) 

=>  CurrentNode  (E),  CurrentDepth  (/-l),  return  (Nil). 
5.    Downward  Motion:  Shift  Needed 

When  the  focus  has  reached  the  depth  limit,  it  is  moving  out  of  the  bottom  of  the  displayed  region  of  the 
tree.  Therefore  it  is  necessary  for  the  display  to  "zoom  in"  to  keep  the  displayed  region  visible.  This  is 
accomplished  by  shifting  the  display  root  to  the  parent  of  the  new  focus.  This  rapid  zooming  works  well 
when  the  user  is  moving  down  into  the  tree  rapidly. 

*SetCurrentNode  (return,  X),  *CurrentNode  (E),  Component  (X,  — ,  E),  *DisplayRoot  (— ), 
*CurrentDepth  (/),  DepthLimit  (d),  if  (l^d) 

=>  CurrentNode  (X),  DisplayRoot  {E),  CurrentDepth  (1),  return  (Nil). 
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6.  Downward  Motion:  No  Shift  Needed 

Where  the  depth  limit  has  not  been  reached,  the  focus  is  simply  shifted  to  the  new  node. 

*SetCurrentNode  (return,  X),  *CurrentNode  (E),  Component  (X,  — ,  E), 
DepthLimit  (d),  CurrentDepth  (/),  if  (/<<f) 

=*•  CurrentNode  (X),  CurrentDepth  (/+l),  return  (Nil). 

7.  Arbitrary  Motion 

All  of  the  preceding  cases  assume  that  the  focus  is  being  shifted  to  a  point  neighboring  the  old  focus.  How- 
ever, search  commands  may  move  the  focus  large  distances.  In  these  cases  we  set  the  display  root  two 
nodes  above  the  new  focus,  provided  the  tree  extends  up  that  far,  otherwise  it  is  set  as  high  as  possible. 

*SetCurrentNode  (return,  E),  *CurrentNode  (-),  *CurrentDepth  (-),  *DisplayRoot  (-) 

=>  {CurrentNode  (E); 

Component  (E,  — ,  F),  Component  (F,  — ,  G)    !  set  root  two  above 

=s>  CurrentDepth  (2),  DisplayRoot  (G) 
else  Component  (E,  — ,  F)    !  set  root  one  above 

=>  CurrentDepth  (1),  DisplayRoot  (F) 
else  CurrentDepth  (0),  DisplayRoot  (E);    !  set  root  here 
return  (Nil)  } 

C.   Editing 

1.    Node  Deletion 

We  must  "untag"  the  node  (making  it  undefined),  and  sever  all  connections  between  it  and  its  descen- 
dents. 

*Command  (return,  delete),  CurrentNode  (E),  *Type  (7,  E) 
=>  Purge  (return,  E). 

The  Purge  relation  removes  all  the  relevant  Component  tuples: 
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*Purge  (return,  E),  Component  {X,  —,  E) 
=>  — 'Component  (X,  —,  E),  Purge  (return,  E) 

else  *Purge  (return,  E) 

=>  Command  (return,  display). 

D.    Program  Entry 

When  a  key  is  struck  we  must  ensure  it  is  not  an  executive  command  (delete,  in,  out,  etc.).  To  do  this 
we  will  use  a  relation  ExecutiveCommand,  which  contains  all  the  executive  command  characters.  When  a 
program  entry  key  is  struck,  we  begin  searching  for  its  meaning  with  the  nonterminal  expected  at  that 
point. 

1.    Initiate  Search 

We  ensure  that  the  key  is  not  an  executive  command  and  that  the  current  node  is  undefined.  Then  we 
determine  from  the  template  associated  with  the  type  of  its  parent  the  syntactic  category  expected  at  this 
point.    The  search  begins  with  the  selector  keys  associated  with  this  category. 

*Command  (return,  k),  — 'ExecutiveCommand  (k),  CurrentNode  (E), 
^Type  (-,  E),  Component  [E,  R,  P),  Type  (  V,  P), 
AssumedTemplate  ( T,   V),  Selector  {R,  I,  T),  Category  (M,  /,  T) 

=>  {OriginalNode  {E); 
ProcessKey  {k,  E,  M}; 
-■OriginalNode  (E); 
return  (Nil)  }. 

The  relation  OriginalNode  saves  the  original  node  for  restoration  if  the  entered  key  is  illegal.  This  is  neces- 
sary since  the  forwarding  process  (optimistically)  creates  and  focuses  on  subnodes  as  it  forwards  the  key 
from  nonterminal  to  nonterminal.  See  the  rule  for  illegal  key  processing  (below)  for  the  use  of  Original- 
Node. 
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2.  Key  Search 

If  the  given  key  is  one  of  the  selectors  for  this  nonterminal,  then  the  appropriate  node  type  is  instantiated. 

*ProcessKey  (return,  k,  E,  M),  VariantKey  (Jb,  V,  M),  Template  ( T,  V,  M) 
=s>  {Type  (V,  E);  Instantiate  (return,  T,  E)} 

If  it  is  not,  then  it  is  forwarded  to  another  nonterminal,  if  one  is  specified,  otherwise  an  error  occurs.   There 
are  two  cases  depending  on  whether  or  not  the  template  is  complex: 

else  *ProcessKey  (return,  Jb,  E,  M),  DefaultNT  (JV,  M),  -Complex  (T) 
=>  ProcessKey  (return,  k,  E,  N) 

else  *ProcessKey  (return,  k,  E,  M),  Default Var  (V,  M),  DefaultTemplate  ( T,  M), 

Complex  {T),  FirstSelector  {R,  T),  Selector  (R,  I,  T),  Category  {N,  I,  T) 
=^{Type(T,  V); 

Instantiate  {  T,  E); 

Component  (X,  R,  E)  =?>  ProcessKey  (return,  k,  X,  N) 

Note  that  the  preceding  rule  automatically  instantiates  nodes.    It  is  this  action  that  necessitates  the  use  of 
OriginalNode  in  the  following  rule;  whatever  nodes  have  been  added  are  deleted: 

else  *ProcessKey  (return,  k,  E,  M),  OriginalNode  (X),  Type  (— ,  X) 
=>  {SetCurrentNode  {X}; 

Command  {delete}; 

Error  (return,  "Illegal  Key:  "  A  k)  }. 

The  presence  of  instantiated  nodes  are  detected  by  a  defined  Type.    The  following  rule  handles  the  case 
where  no  nodes  were  instantiated. 

else  *ProcessKey  (return,  k,  E,  M)    !  nodes  have  not  been  instantiated 
=>  Error  (return,  "Illegal  Key:  "  *  k). 

3.  Node  Instantiation:  First  Selector 

The  first  component  of  the  new  node  is  distinguished  from  the  rest  because  the  focus  is  automatically 
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shifted  to  this  component.    This  facilitates  left-to-right  program  entry.    The  following  rule  allocates  a  new 
node,  makes  it  the  first  component,  and  makes  it  the  new  focus: 

■"Instantiate  (return,  T,  E),  FirstSelector  {R,  T),  *Avail  (X) 

=?•  Component  (X,  R,  E),  SetCurrentNode  {X},  InstantiateRest  (return,  R,  T,  E). 
4-    Node  Instantiation:  Other  Selectors 

The  remaining  component  nodes  are  created  by  an  iterative  process.    When  this  has  completed,  the  altered 
tree  is  unparsed,  so  that  the  user  can  see  the  template  for  the  new  node. 

*InstantiateRest  (return,  R,  T,  E),  NextSelector  (5,  R,  T),  *Avail  (X) 
=>  Component  (X,  5,  E),  InstantiateRest  (return,  S,  T,  E). 

*InstantiateRest  (return,  R,  T,  E),  -iNextSelector  (— ,  R,  T) 
=5>  Command  (return,  display). 

E.    String  Entry 

The  command  processor  recognizes  the  spacebar  command  and  accumulates  into  the  Argument  relation 
all  characters  typed  up  to  the  next  return  character.  This  command  is  allowed  only  if  <chars>  is  the  non- 
terminal associated  with  the  current  node. 

For  example,  consider  the  grammar  rule: 

#  -+  <chars> 
=s>    Con  (LitVal=<chars>) 

The  generated  tuples  are: 

Type  (Con,  E), 

Component  (  V,  LitVal,  E) 

Type  (Chars,  V), 

Component  ("c^  ■  ■  •  cn",  "charval",   V) 

The  extra  level  of  indirection  is  necessary  to  allow  editing  the  string  value. 
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1.  Program  Entry:  Spacebar  Command 

If  the  current  node  is  undefined,  but  a  string  is  expected,  then  the  accumulated  argument  is  made  the 
string  associated  with  the  node,  which  is  now  of  type  Chars. 

*Command  (return,  spacebar),  *Argument  (s),  CurrentNode  [E), 
^Type  (-,  E),  Component  {E,  R,  P),  Type  {V,  P), 
AssumedTemplate  ( T,  V),  Selector  (i?,  /,  T),  Category  (String,  /,  T) 

=5-  Type  (Chars,  E),  Component  (s,  "charval",  E),  Command  (return,  display). 
The  rule  arrangement  in  Appendix  A  is  slightly  different,  but  not  significantly  so. 

2.  Alternate  String  Entry 

The  need  to  type  the  spacebar  could  be  eliminated  by  making  all  commands  (both  executive  and  selector) 
nonprintable  characters  (e.g.,  control  codes).  Then,  any  printable  character  would  automatically  start 
string  accumulation.  Alternately,  positioning  the  cursor  on  an  undefined  node  of  type  <chars>  could 
automatically  trigger  string  accumulation. 

F.   Unparsing 

The  following  sections  describe  the  rules  for  unparsing  the  visible  region  of  the  program  tree.    Unparsing  is 
initiated  by  the  display  command,  which  may  be  issued  by  the  user  or  by  the  system  (e.g.,  during  edit- 
ing)- 
I.    display  Command 

Begin  at  the  display  root: 

*  Command  (return,  display),  Display  Root  (E),  Type  (— ,  E) 
=*  Unparse  {E),  Waitlmage  (return,  E). 

The  Unparse  relation  requests  the  unparsing  to  start  at  E.    The  unparsed  form  is  returned  in  Finallmage: 

*  Waitlmage  (return,  E),  *FinalImage  («,  E) 
=>  return  (Display  {«}). 
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SL   Begin  Unparsing 

Select  a  template  based  on  the  type  of  node: 

*Unparse  (E),  Type  (V,  E),  AssumedTemplate  ( T,  V) 

=*  Scan  (E,  T,  0). 

This  requests  E  to  be  unparsed  (scanned)   according  to  template   T.    The  '0'  indicates  that  the  current 
display  depth  is  zero. 

3.    Begin  Image  Accumulation 

To  scan  according  to  a  template,  we  begin  processing  the  first  item  in  the  template,  starting  with  an  empty 
image: 

*Scan  [E,  T,  I) 

=>  Processltem  [E,  T,  "",  /). 

4-    Terminals 

A  terminal  string  is  added  to  the  image  accumulated  so  far: 

*ProcessItem  (E,  I,  s,  I),  Terminal  (/),  Terminallmage  (i,  /) 

=>  MoveRight  (E,  I,  s  't,  I). 
5.    Move  Right 

The  MoveRight  relation  finds  the  next  item  in  the  template,  or,  if  there  is  none,  completes  processing  of 
the  image. 

*MoveRight  (E,  I,  s,  I),  Nextltem  (J,  I,  N), 

=s-  Processltem  (E,  J,  s,  /) 

else  *MoveRight  (E,  7,  s,  I) 
=>  Image  («,  E). 
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6.  Nonterminal:  Component  Node 

Find  the  associated  selector  and  through  it  initiate  unparsing  of  the  selected  component. 

*ProcessItem  (E,  I,  s,  I),  — 'Terminal  (/),  Selector  (R,  I,  T), 
Component  (X,  R,  E),  Category  (N,  I,  T),  Complex  (T) 

=*  Pending  {E,  I,  s,  X,  I),  FindTemplate  (X,  N,  l  +  l). 

The  Pending  relation  waits  until  the  component  is  unparsed.    FindTemplate  requests  unparse  of  the  com- 
ponent at  display  level  /+1. 

7.  Nonterminal:  Entire  Node 

This  occurs  in  simplex  (as  opposed  to  complex)  templates.    It  is  triggered  by  the  absence  of  a  selector  for 
the  nonterminal  item. 

*ProcessItem  [E,  I,  «,  /),  —■Terminal  (/),  Category  (N,  I,  T),  -'Complex  ( T) 

=*  Pending  {E,  I,  s,  E,  I),  FindTemplate  {E,  N,  I). 

8.  Nonterminal:  Complete  Processing 

When  a  final  image  has  been  computed  for  a  pending  nonterminal,  we  move  right  to  the  next  item  in  the 
template: 

*Pending  [E,  I,  s,  X,  I),  *FinalImage  [t,  X) 

=>  MoveRight  (E,  I,  s't,  I). 

9.  Find  Template:  Undefined  Node 

If  the  node  is  undefined,  its  image  is  the  name  of  the  nonterminal  expected: 
♦FindTemplate  (E,  N,  I),  -Type  (-,  E),  Nonterminallmage  (s,  N) 

=>  Image  ("<"  "  s   "  ">",  E). 
The  Image  relation  is  an  intermediary  before  Finallmage,  which  is  discussed  later. 
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10.  Find  Template:  Suppress  Detail 

If  the  subtree  is  below  the  depth  limit,  then  replace  it  by  an  ellipsis: 

*FindTemplate  {E,  N,  I),  Type  (-,  E),  DepthLimit  (d),  if  l>d 
=>  Image  ("...",  E). 

Note  that  this  rule  is  not  used  on  undefined  nodes. 

11.  Find  Template:  Selected  Template 

Select  a  template  based  on  the  type  of  the  node: 

*FindTemplate  {E,  N,  I),  Type  (  V,  E),  Template  (T,  V,  N),  DepthLimit  {d),  if  Kd 

=>  Scan  (E,  T,  I). 

12.  Find  Template:  Default  Template 

If  there  is  no  template  corresponding  to  the  node  type,  then  use  the  default  template: 

"*FindTemplate  {E,  N,  I),  Type  (  V,  E),  -Template  (-,   V,  N), 
DefaultTemplate  (T,  N),  DepthLimit  {d),  if  Kd 

=*  Scan  {E,  T,  I). 
IS.    Find  Template:  Leaves 

We  must  handle  specially  the  "leaves,"  that  is,  the  nodes  corresponding  to  the  <chars>  nonterminal: 
*FindTemplate  (E,  String,  /),  Type  (Chars,  E),  Component  («,  "charval",  E) 

=*•  Image  (s,  E). 
14.    Final  Image  from  Image 

The  final  image  is  computed  from  the  image  by  toggling  inverse  video  when  we  pass  the  focus  node: 
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*Image  («,  E),  CurrentNode  (E),  if  («  #  Nil  A  first  «  #  inverton) 
==>  Finallmage  (invert_on      <      invert_off,  .E) 

else  *Image  («,  E1) 
=*  Finallmage  («,  E1). 

V.    Conclusions 

The  investigation  reported  in  "Experience  with  £7:  Implementation  of  a  Prototype  Programming  Environ- 
ment," Parts  I  through  VI,  has  given  us  considerable  experience  in  the  use  of  Q  for  a  nontrivial  applica- 
tion. We  have  gained  some  insight  into  the  difficulties  of  programming  a  complex,  highly-concurrent  sys- 
tem in  an  object-oriented  language.  This  has  convinced  us  that  object-oriented  languages  need  some 
powerful  linguistic  mechanisms  to  help  programmers  think  about  time  and  control  the  relationship  of 
events  in  time. 

We  now  believe  that  some  form  of  modal  or  temporal  logic,  built  into  the  language,  is  the  best  approach 
to  this  problem.  In  particular,  in  future  research  we  intend  to  design  linguistic  structures  that  define  tem- 
poral domains  in  much  the  same  way  that  the  control  structures  and  scope  structures  of  conventional 
languages  define  control-flow  and  naming  domains.  The  goal  of  the  linguistic  structures  is  to  avoid  the 
complicated  reasoning  common  to  the  use  of  first-order  temporal  logics. 
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APPENDIX  A:   Universal  Syntax-Directed  Editor 

The  following  is  a  loadable  input  61e  ('PI6.USDE')  for  the  prototype  universal  syntax-directed  editor 
described  in  this  report.  It  is  accepted  by  the  Mc Arthur  interpreter  [McArthur84],  which  differs  in  a  few 
details  from  the  Ct  notation  used  in  this  report  (see  [MacLennan84]). 

I 

!    USDE  —  Universal  Syntax  Directed  Editor 

i 

!    RELATION  DECLARATIONS 

!    User  Interface 

newrelation  {"Command"}; 
newrelation  {"Argument"}; 
newrelation  {"Error"}; 

!    Kinds  of  Templates 

newrelation  {"Template"}; 
newrelation  {"DefaultTemplate"}; 
newrelation  {"Complex"}; 

!    Parts  of  Templates 

newrelation  {"Nextltem"}; 
newrelation  {"Terminal"}; 
newrelation  {"Terminallmage"}: 

!    Nonterminals 

newrelation  {"Selector"}; 
newrelation  {"Category"}; 
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newrelation  {"Nonterminallmage"}: 

!   Display  Control 

newrelation  {"Root"}; 
newrelation  {"DisplayRoot"}; 
newrelation  {"CurrentNode"}; 
newrelation  {"OriginalNode"}; 
newrelation  {"DepthLimit"}; 
newrelation  {"CurrentDepth"}: 
newrelation  {"AssumedTemplate"}; 

!    Variant  Selection 

newrelation  {"ExecutiveCommand"}; 
.  newrelation  {"VariantKey"}; 
newrelation  {"DefaultNT"}; 
newrelation  {"DefaultVar"}; 

!    Node  Format 

.  newrelation  {"FirstSelector"}: 
newrelation  {"NextSelector"}; 
newrelation  {"LastSelector"}; 

!    Node  Structure 

newrelation  {"Type"}; 
newrelation  {"Component"}; 

!    Activities 

newrelation  {"SetCurrentNode"}; 
newrelation  {"Purge"}; 
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newrelation 
newrelation 
newrelation 
newrelation 
newrelation 
newrelation 
newrelation 
newrelation 
newrelation 
newrelation 
newrelation 
newrelation 
newrelation 
newrelation 
newrelation 


{"Instantiate"}: 

{"Image"}; 

{"Finallmage"}; 

{"FindTemplate"}; 

{"Pending"}; 

{"MoveRight"}; 

{"Processltem"}; 

{"Scan"}; 

{"Unparse"}; 

{"Waitlmage"}; 

{"InstantiateRest"}; 

{"ProcessKey"}; 

{"CreateFirst"}; 

{"CreateRest"}; 

{"CreateRoot"}. 


!    Format  Control  Strings 

define  {root,  "NL".  " 

"}: 

define  {root.  "invert_on".  "{"}; 

define  {root.  "invert_off".  "}"}. 

!    chars    —    a  special  buiitin  nonterminal 

define  {root,  "chars",  newobj  {}}. 
AssumedTemplate  (newobj  {}.  "chars"); 
Nonterminallmage  ("chars",  chars). 

!    Table  of  Executive  Commands 

ExecutiveCommand  ("in"): 
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ExecutiveCommand 
ExecutiveCommand 
ExecutiveCommand 
ExecutiveCommand 
ExecutiveCommand 
ExecutiveCommand 
ExecutiveCommand 


"out"): 

"next"); 

"prev"): 

"root"): 

"display"): 

"delete"): 

"begin"). 
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»  THE  RULES 

define  {root.  "UnivSDErules".  << 

!    Error  Handler 

if  *Error  (return,  message) 

—  >  return  (displayn  {message}); 

!    Focus  Movement: 

!    in  Command 

if  'Command  (return,  "in").  CurrentNode  (E).  Type  (V.  E).  AssumedTemplate  (T.  V), 
FirstSelector  (R,  T).  Component  (X.  R.  E) 
->  {SetCurrentNode  {X};   Command  (return,  "display")} 

else  if  'Command  (return,  "in") 

—  >  Error  (return.  "No  inner  component"); 

!   out  Command 

if  'Command  (return,  "out").  CurrentNode  (X).  Component  (X.  — .  E) 

—  >  {SetCurrentNode  {E};    Command  (return,  "display")} 

else  if  'Command  (return,  "out") 

->  Error  (return,  "No  outer  component"); 

!    next  Command    (next  on  same  level) 

if  'Command  (return,  "next").  CurrentNode  (X).  Component  (X.  R.  E).  Type  (V.  E). 
AssumedTemplate  (T.  V).  NextSelector  (S.  R,  T),  Component  (Y.  S.  E) 

—  >  {SetCurrentNode  {Y};    Command  (return,  "display")}; 

!   next  Command    (next  on  level  above) 
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if  ^Command  (return,  "next").  CurrentNode  (X).  Component  (X.  R.  E).  Type  (V.  E). 
AssumedTemplate  (T.  V).  "NextSelector  (— .  R.  T) 
->  {SetCurrentlMode  {E};    Command  (return,  "next")}; 

!    next  Command  (no  next  node) 

if  'Command  (return,  "next"),  CurrentNode  (X).  "Component  (X.  R.  E) 

—  >  Error  {"No  next  component"}; 

!    prev  Command  (prev  on  same  level) 

if  'Command  (return,  "prev").  CurrentNode  (X).  Component  (X.  R.  E).  Type  (V,  E). 
AssumedTemplate  (T.  V).  NextSelector  (R.  S.  T).  Component  (Y.  S.  E) 
->  {SetCurrentNode  {Y}:    Command  (return,  "display")}; 

!    prev  Command  (prev  on  level  above) 

if  'Command  (return,  "prev"),  CurrentNode  (X).  Component  (X,  R.  E),  Type  (V.  E). 
AssumedTemplate  (T.  V).  "NextSelector  (R.  S,  T) 

—  >  {SetCurrentNode  {E};  Command  (return,  "prev")}; 

!    prev  Command  (no  prev  node) 

if  *Command  (return,  "prev").  CurrentNode  (X),  "Component  (X.  R.  E) 

—  >  Error  {"No  prev  component"}; 

!    root  Command 

if  *Command  (return,  "root").  Root  (E) 

->  {SetCurrentNode  {E};  Command  (return,  "display")}; 

!    Upward  Motion:  Shift  Needed 

if  'SetCurrentNode  (return.  E).  *CurrentNode  (X),  Component  (X.  — .  E).  *DisplayRoot  (X). 
*CurrentDepth  (— ).  Component  (E.  — .  D) 
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->  DisplayRoot  (D).  CurrentNode  (E).  CurrentDepth  (1).  return  (Nil) 

f   Upward  Motion:  No  Shift  Needed 

|     else  if  *SetCurrentNode  (return,  E).  *CurrentNode  (X),  Component  (X.  — ,  E),  *CurrentDepth  (I) 

i 

j      ->  CurrentNode  (E),  CurrentDepth  (1-1).  return  (Nil) 

i 

j      !    Downward  Motion:  Shift  Needed 

i 
i 

else  if  *SetCurrentNode  (return.  X).  *CurrentNode  (E).  Component  (X.  — .  E). 
j       *DisplayRoot  (-).  *CurrentDepth  (I).  DepthLimit  (d).  I  >=  d 

->  CurrentNode  (X),  DisplayRoot  (E).  CurrentDepth  (1),  return  (Nil) 

| 

I      !    Downward  Motion:  No  Shift  Needed 

else  if  *SetCurrentNode  (return.  X).  *CurrentNode  (E).  Component  (X.  — ,  E). 
DepthLimit  (d),  *CurrentDepth  (I).  I  <  d 
->  CurrentNode  (X),  CurrentDepth  (1+1).  return  (Nil) 

!    Arbitrary  Motion:  Default  Case 

I 

i      else  if  *SetCurrentNode  (return,  E).  *CurrentNode  (— ).  *CurrentDepth  (-),  *DisplayRoot  (— ) 
i 

->  {CurrentNode  (E); 

!  if  Component"(E.  — ,  F),  Component  (F.  — ,  G)    !  set  root  two  above 

->  CurrentDepth  (2).  DisplayRoot  (G) 

else  if  Component  (E.  — .  F)    !  set  root  one  above 

->  CurrentDepth  (1).  DisplayRoot  (F) 

j  else  CurrentDepth  (0).  DisplayRoot  (E);    !  set  root  here 

return  (Nil) 

}: 

!    Editing  Node  Deletion 

if  *Command  (return,  "delete").  CurrentNode  (E).  *Type  (V.  E) 
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— >  Purge  (return.  E); 

if  *Porge  (return.  E).  Component  (X.  — .  E) 
->  "Component  (X.  — .  E).  Purge  (return.  E) 

else  if  *Purge  (return.  E) 

->  Command  (return,  "display"); 

!    Program  Entry:  Initiate  Search 

if  *Command  (return,  k).  "ExecutiveCommand  (k).  CurrentNode  (E).  "Type  (— .  E). 
Component  (E.  R.  P).  Type  (V.  P),  AssumedTemplate  (T.  V).  Selector  (R.  I.  T). 
Category  (M.  I.  T) 

t 

—  >  {OriginalNode  (E): 

ProcessKey  {k.  E.  M}; 
"OriginalNode  (E). 
return  (Nil)}; 

!    Program  Entry:  Key  Search 

if  *ProcessKey  (return,  k.  E.  M).  VariantKey  (k.  V.  M).  Template  (T.  V.  M) 
->  {Type  (V.  E):  Instantiate  (return.  T.  E)  } 

else  if  *ProcessKey  (return,  k.  E.  M).  DefaultNT  (N.  M),  DefaultTemplate  (T.  M).  "Complex  (T) 

—  >  ProcessKey  (return,  k.  E.  N) 

else  if  *ProcessKey  (return,  k.  E.  M).  DefaultVar  (V.  M).  DefaultTemplate  (T.  M). 
Complex  (T).  FirstSelector  (R.  T).  Selector  (R.  I.  T).  Category  (N.  I.  T) 
->  {Type  (V.  E); 

Instantiate  {T.  E}; 

if  Component  (X.  R.  E)  — >  ProcessKey  (return,  k.  X.  N) 

> 
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!   Process  Character  Entry 

else  if  *ProcessKey  (return.  "  ",  E,  chars).  *  Argument  (s) 

— >  Type  ("chars".  E),  Component  (s.  "charval".  E).  Command  (return,  "display"] 

else  if  *ProcessKey  (return.  "  ".  E.  M).  *  Argument  (— ) 
— >  Error  (return.  "Characters  not  expected") 

!    Process  Illegal  Key 

else  if  *ProcessKey  (return,  k.  E.  M).  OriginalNode  (X).  Type  (— .  X) 
->  {SetCurrentNode  {X}; 

Command  {"delete"}; 

Error  (return.  "Illegal  Key:  "  +  k) 
} 

else  if  *ProcessKey  (return,  k.  E.  M)    !  nodes  have  not  been  instantiated 
->  Error  (return.  "Illegal  Key:  "  +  k); 

!    Node  Instantiation  First  Selector 

if  'Instantiate  (return.  T.  E).  FirstSelector  (R.  T) 
->  CreateFirst  (return.  T.  E.  R.  newobj  {}); 

if  *CreateFirst  (return,  T.  E.  R.  X) 

->  Component  (X.  R.  E).  SetCurrentNode  {X}.  InstantiateRest  (return.  R.  T.  E); 

!    Node  Instantiation:  Other  Selectors 

if  *lnstantiateRest  (return.  R,  T.  E).  NextSelector  (S.  R.  T) 
->  CreateRest  (return,  R.  T,  E.  S,  newobj  {}); 

if  *CreateRest  (return.  R.  T.  E.  S.  X) 

->  Component  (X.  S.  E).  InstantiateRest  (return.  S.  T,  E): 
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if  *lnstantiateRest  (return.  R.  T.  E).  "NextSelector  (-.  R.  T) 
— >  Command  (return,  "display"): 

!    Alternate  String  Entry 

!    Unparsing:  display  Command 

if  'Command  (return,  "display").  Display  Root  (E),  Type  (— .  E) 

—  >  Unparse  (E).  Waitlmage  (return.  E) 

else  if  Command  (return,  "display").  Display  Root  (X).  Component  (X.  — .  E).  *CurrentDepth  (- 
->  DisplayRoot  (E).  CurrentDepth  (1); 

if  *Waitlmage  (return.  E),  *Finallmage  (s.  E) 

—  >  return  (displayn  {s}); 

!    Begin  Unparsing 

!    Select  a  template  based  on  the  type  of  node: 

if  *Unparse  (E).  Type  (V.  E).  AssumedTemplate  (T.  V) 
->  Scan  (E.  T.  0); 

!    Begin  Image  Accumulation 

if  *Scan  (E.  T.  I) 

->  Processltem  (E.  T.  "".  I); 

!    Terminals 

if  *Processltem  (E.  I,  s.  I),  Terminal  (I).  Terminallmage  (t.  I) 
->  MoveRight  (E.  I.  s  +  t.  I); 

!    Move  Right 

if  'MoveRight  (E.  I.  s.  I).  Nextltem  (J.  I.  N) 
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— >  Processltem  (E.  J.  s,  I) 

efce  if  *MoveRight  (E.  I.  s.  I) 
—  >  Image  (s.  E); 

!    Nonterminal:  Component  Node 

if  *Processltem  (E.  I.  s.  I).  "Terminal  (I).  Selector  (R.  I.  T). 
Component  (X.  R,  E).  Category  (N,  I.  T),  Complex  (T) 
->  Pending  (E.  I.  s.  X.  I).  FindTemplate  (X.  N,  1+1); 

!    Nonterminal  Entire  Node 

if  *Processltem  (E,  I.  s.  I),  "Terminal  (I).  Category  (N.  I.  T).  "Complex  (T) 
->  Pending  (E.  I.  s.  E.  I).  FindTemplate  (E.  N.  I): 

!    Nonterminal:  Complete  Processing 

if  *Pending  (E.  I.  s,  X.  I).  *Finallmage  (t.  X) 
->  MoveRight  (E.  I.  s  +  t.  I): 

!    Find  Template:  Undefined  Node 

if  *FindTemplate  (E.  N.  I),  "Type  (— .  E),  Nonterminallmage  (s.  N) 
->  Image  ("<"  +  s  +  ">".  E); 

!    Find  Template:  Suppress  Detail 

if  *FindTemplate  (E.  N.  I).  Type  (-.  E).  DepthLimit  (d).    I>d 
->  Image  ("...",  E): 

!    Find  Template:  Selected  Template 

if  *FindTemplate  (E.  N.  I).  Type  (V.  E).  Template  (T.  V.  N).  DepthLimit  (d).  I  <=  d 
->  Scan  (E.  T.  I): 
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1    Find  Template:  Default  Template 

Iff  *F*mdTemplate  (E.  N.  I).  Type  (V.  E).  "Template  (-.  V.  N), 
DefaultTemplate  (T,  N).  DepthLimit  (d).  I  <=  d 
->  Scan  (E.  T.  I); 

!    Find  Template:  Leaves 

if  *FindTemplate  (E.  chars,  I).  Type  ("chars".  E).  Component  (s.  "charval".  E) 
->  Image  (s.  E): 

!    Final  Image  from  Image 

if  *lmage  (s.  E).  CurrentlMode  (E).  s  !=  Nil.  first  [s]  !=  invert^on 

—  >  Finallmage  (invert_on  +  s  +  invert_off.  E) 

else  if  *lmage  (s.  E) 
->  Finallmage  (s,  E); 

!    begin  Command 

if  *Command  (return,  "begin") 

—  >  CreateRoot  (return,  newobj  {}.  newobj  {}); 

if  *CreateRoot  (return.  E.  P) 

->  {Type  ("prog".  P).  Root  (P).  Component  (E.  "*".  P).  DisplayRoot  (P).  CurrentlMode  (E): 
Command  (return,  "display")}: 

»}. 

act  {UnivSDErules}. 

!    Initialize  Parameters 

DepthLimit  (5): 
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CurrentDepth  (1). 

displayn  {"Universal  SDE  loaded."}. 
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APPENDIX  B:   Table  Builder  for  Universal  SDE 

The  following  is  a  loadable  input  file  ('Pl6.util')  defining  the  table  building  and  other  utility  rules  for  the 
universal  syntax-directed  editor.    It  assumes  the  definitions  of  Appendix  A. 


Utility  Relations  and  Rules  for  USDE 


I 


newrelation 

newrelation 
newrelation 

newrelation 
newrelation 
newrelation 
newrelation 
newrelation 
newrelation 

newrelation 
newrelation 
newrelation 
newrelation 

newrelation 
newrelation 
newrelation 
newrelation 
newrelation 
newrelation 


"newobject"}; 

"defnt"}; 

"defnt2"}: 

"CrTempI"}; 
"CrTempIO"} 
"CrTempIl"} 
"CrTemptf" } 
"CrTempl3"} 
"CrTempl4"} 

"CrVar"}: 
"CrDef"}: 
"CrSimDef"}; 
"DefSel"}; 

"PrNT"}; 

"PrVariant"}; 

"PrSimDef"}; 

"PrDef"}; 

"PrTempI"}; 

"PrTempIl"}; 
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newrelation  {"Script"}: 
newrelation  {"PendScript"}. 

define  {root.  "PI6util".  << 

!    newobject  {n}    —    defines  a  new  object  named   n' 

if  *newobject  (return.  N) 

—  >  {define  {root.  N.  newobj  {}};  return  (Nil)}; 

!    defnt  {nt}    —    define  nonterminal  named  'nt' 

if  *defnt  (return.  S) 

—  >  defnt2  (return.  S.  newobj{}); 

if  *defnt2  (return.  S.  IM) 

—  >  {define  {root.  S.  N};    IMonterminallmage  (S,  N)}; 

!    CrTempI  {NT,  templ-descr}    -    construct  template:  return  1st  item 

if  *CrTempl  (return.  N.  Nil) 

—  >  {display  {"Error:  empty  template  for  "}:  displayn  {N}} 

else  if  *CrTempl  (return.  N,  Z) 

—  >  CrTempIO  (return,  N.  Z.  newobj  {}): 

if  *CrTemplO  (return.  N.  Z.  T) 
->  CrTempIl  (return,  N.  Z.  T,  T); 

if  *CrTempll  (return,  N.  Z.  T,  I) 
->  {if  IsList  [first  [Z]] 

->  CrTempl2  (return.  N,  first  (rest  [first  [Z]J].  first  [first  [Z]]. 
rest  [Z],  T.  I) 
else  CrTempl3  (return.  N.  first  [Z],  rest  [Z],  T.  I)  }; 
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if  *OTempl2  (return.  N.  M.  R.  Z.  T.  I) 
->  {Selector  (R.  I.  T).  Category  (M.  I.  T): 

DefSel  {R.  T}; 

CrTempl4  (return.  N.  Z.  T.  I.  N) 

}: 

if  *CrTempl3  (return.  N.  S.  Z.  T.  I) 

->  Terminal  (I).  Terminallmage  (S.  I).  CrTempl4  (return.  IM.  Z.  T.  I.  N); 

if  *CrTempl4  (return.  N.  Nil.  T.  I.  N) 
—  >  return  (I) 

else  if  *CrTempl4  (return.  N.  Z.  T.  I,  N) 

->  Nextltem  (CrTempIl  {N.  Z.  T.  newobj  {}}.  I.  N).  return  (I); 

!    CrVar  {NT.  key.  type,  template} 
!    Create  variant 

if  *CrVar  (return.  N.  K,  V.  Z) 

->  {VariantKey  (K.  V.  N).  Template  (CrTempI  {N.  Z}.  V.  N); 

if  Template  (T.  V.  N)  ->  AssumedTemplate  (T.  V).  Complex  (T); 

return  (Nil) 

}: 

!    CrDef  {NT.  default  variant,  template} 
!    Create  default 

if  *CrDef  (return.  M.  V.  Z) 

->  {DefaultVar  (V.  M).  DefaultTemplate  (CrTempI  {M.  Z}.  M); 

if  DefaultTemplate  (T.  M)  ->  AssumedTemplate  (T.  V),  Complex  (T): 

return  (Nil) 

}: 
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?   CrStmDef  {NT.  left.  NT',  right}    -    Create  simplex  default 

if  *CrSimDef  (return.  M.  s.  N.  t) 

->  {DefaultNT  (N.  M).  DefaultTemplate  (CrTempI  {M.  [s.  ["*".  N].  tj}.  M); 

return  (Nil) 

}: 

!    DefSel  {R,  template}    —    Define  next  selector  for  template 

if  *DefSel  (return.  R.  T).  'LastSelector  (-.  T) 

->  FirstSelector  (R.  T).  LastSelector  (R.  T).  return  (Nil): 

if  *DefSel  (return.  S.  T).  *LastSelector  (R.  T) 

->  NextSelector  (S.  R.  T).  LastSelector  (S.  T).  return  (Nil); 

!    PrNT  {NT}    -    print  nonterminal's  name 

if  *PrNT  (return.  N).  Nonterminallmage  (S,  N) 
->  {displayn  {""};  displayn  {S  +  ":"}}; 

!    PrVariant  {NT.  key}    -    print  selected  variant 

if  *PrVariant  (return,  N.  K),  VariantKey  (K.  V.  N).  Template(T,  V.  N),  Complex  (T) 
->  {display  {"""  +  K  +  "'("  +  V  +  ")  ->  "}: 

return  (PrTempI  {T}) 

}: 

!    PrSimDef  {NT}  —  print  simplex  default  variant 

if  *PrSimDef  (return.  M).  DefaultNT  (N.  M).  DefaultTemplate  (T.  M) 
->  {display  {"else  <"};  display  {N};  display  {">  ->  "}; 
return  (PrTempI  {T}) 

}: 
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t  PrDef  {NT}    -    print  complex  default  variant 

if  *PrDef  (return.  M).  DefaultVar  (V.  M).  DefaultTemplate  (T,  M) 
->  {display  {"else  ("  +  V  +  ")  ->  "}: 
return  (PrTempI  {T}) 

}: 
!    PrTempI  {item}    -   print  template 

if  *PrTempl  (return.  I).  Terminal  (I).  Terminallmage  (S.  I) 
->  {display  {"  '"  +  S  +  "'"}:  return  (PrTempIl  {I})}; 

if  *PrTempl  (return.  I).  Selector  (R.  I.  T).  Category  (M.  I.  T) 
->  {display  {"  "  +  R  +  ":<"};  display{M};  display  {">"}; 
return  (PrTempIl  {I}) 

}: 

if  *PrTempll  (return.  I).  "Nextltem  (J.  I.  N) 
->  display n  {»."} 

else  if  *PrTempll  (return.  I).  Nextltem  (J.  I,  N) 

—  >  PrTempI  (return,  J); 

!    Script  {s}    —    Execute  Command  Script  s 

if  *Script  (return.  Nil) 

—  >  return  ("Done") 

else  if  *Script  (return,  s).  first  [sj  =  "  " 

->  {displayn  {" "}; 

displayn  {"  _"  +  first  [rest  [s]]}; 

Argument  (first  [rest  [s]]) 

Command  {first  [s]}; 
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if  "Command  (— .  — )  ->  Script  (return,  rest  [rest  [s]]) 
else  PendScript  (return,  rest  [rest  [s]]) 

} 

else  if  *Script  (return,  s) 

->  {displayn  {" "}; 

display n  {»  "  +  first  [s]}: 

Command  {first  [s]}; 

if  "Command  (— .  — )  ->  Script  (return,  rest  (sj) 

else  PendScript  (return,  rest  [s]) 

}: 

if  *PendScript  (return,  s).  "Command  (— .  — ).  "Waitlmage  (— .  — ) 
—  >  Script  (return,  s); 

»}• 

act  {PI6util}. 

displayn  {"PI— 6  Utilities  activated."}. 
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APPENDIX  C:    Sample  Transaction  Grammar 

The  following  is  a  loadable  input  file  ('Pl6.testgram')  that  constructs  the  grammar  tables  for  the  sample 
language  used  in  the  body  of  the  report. 


!    Transaction  Grammar  for  Simple  Applicative  Language 


!    Define  Nonterminals 

defnt  {"program"}; 
defnt  {"expr"}; 
defnt  {"arex"}; 
defnt  {"term"}; 
defnt  {"factor"}; 
defnt  {"var"}. 

!    <program>    =    (prog)    *:<expr>. 

CrDef  {program,  "prog",  [["*",  expr]]}. 

PrNT  {program}; 
PrDef  {program}. 

!  <expr>: 

!      =  (eql)    ->    left:<arex>  =  right: <arex> 
!      n  (neq)    ->    left:<arex>  <>  right:<arex> 
!      else  <arex> 

CrVar  {expr.  "=",  "eql",  [["left",  arex],  "  =  ",  ["right",  arex]]}; 
CrVar  {expr,  "n".  "neq".  [["left",  arex],  "  <>  ".  ("right",  arex]]}: 
CrSimDef  {expr.  "".  arex.  ""}. 
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PrNT{expr}; 
PrVariant  {expr.  "="}; 
PrVariant  {expr.  "n"}; 
PrSimDef  {expr}. 

!  <arex>: 

!      +  (sum)    ->    left:<arex>  +  right:<term> 
!      —  (dif)    ->    left:<arex>  —  right: < term > 
!      else  <term> 

CrVar  {arex.  M+".  "sum*1,  [["left",  arexj.  "  +  ".  ["right",  term]]}; 
CrVar  {arex.  "-".  "dif".  [["left",  arex].  "  -  ".  ["right",  term]]}; 
CrSimDef  {arex.  "".  term.  ""}. 

PrIMT  {arex}; 
PrVariant  {arex.  "+"}; 
PrVariant  {arex.  "-"}; 
PrSimDef  {arex}. 

!  <term>: 

!  *  (prd)  ->  left:<term>  x  right: <factor> 
!  /  (quo)  ->  left:<term>  /  right: <factor> 
!      else  <factor> 

CrVar  {term.  "*".  "prd".  [["left",  term].  "  x  ".  ["right",  factor]]}; 
CrVar  {term.  "/".  "quo",  [["left",  term],  "  /  ".  ["right",  factor]]}; 
CrSimDef  {term.  "".  factor.  ""}. 

PrNT  {term}; 
PrVariant  {term.  "*"}; 
PrVariant  {term.  "/"}; 
PrSimDef  {term}. 
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!  <factor>: 

•  #  (con)   ->   litval:<chars> 

I  c  (call)    — >    rator:<chars>  rand:<factor> 

!  (  (par)    —  >    (  exp:<expr>  ) 

!  i  (conex)    — > 

!  (if  cond:<expr> 

!  then  conseq:<expr> 

!  else  alt: <expr>    ) 

!  I  (block)    -> 

!  [let  bndvar:<chars>  —  bndval:<expr> 

!  body:<expr>    ] 

!  f  (fundef)    -> 

!  [func  funname:<chars>     funformal:<chars>  =  funbody:<expr> 

!  funscope:<chars>    ] 

!  else  (var)    — >    ident:<chars> 

CrVar  {factor.  "#".  "con",  [["litval".  chars]]}. 
CrVar  {factor,  "c".  "call",  [["rator".  chars],  "  ".  ("rand",  factor]]}; 
CrVar  {factor.  "(".  "par".  ["(".  ["exp".  expr],  ")"]}: 
CrVar  {factor,  "i".  "conex". 
[NL  +  "(if  ".  ("cond".  expr], 
ML  -(-  "  then  ".  ["conseq".  expr]. 
NL  +  "  else  ".  ["alt",  expr].  "  )"]}; 
CrVar  {factor.  "I",  "block". 
[NL  +  "[let  ".  ["bndvar".  chars].  "  =  ".  ["bndval".  expr], 
NL.  ["body",  expr],  "  ]"]}; 
CrVar  {factor,  "f".  "fundef". 
[NL  +  "[func  ".  ["funname".  chars],  "  ".  ["funformal".  chars].  "  =  ",  ["funbody".  expr], 
NL.  ["funscope".  expr],  "  ]"]}; 
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CrDef  {factor,  "var".  [["ident".  chars]]}. 

PrNT  {factor}: 
PrVariant  {factor.  "#"}; 
PrVariant  {factor,  "c"}: 
PrVariant  {factor.  "("}: 
PrVariant  {factor,  "i"}: 
PrVariant  {factor.  "I"}: 
PrVariant  {factor,  "f"}; 
PrDef  {factor}. 

display n  {"Test  Grammar  loaded."}. 

define  {root,  "test; script", 

("begin",  "f".  "  ".  "fac".  "next".  "  ".  "n".  "next", 
ttjtt    ti_n    ti  ti    tif.ii    "next"    "#"    "  "    "0" 

"next"./'#".  "  ".  "1".  "next", 

"*".  "  «,  "n".  "next",  "c".  "  ".  "fac",  "next". 

"_"    "(•'    <•_»    h  n    ttptt    "next"    nSn    "  "    "1"    "next" 

"I",  "  ".  "alpha",  "next".  "*".  "#".  "  ".  "512".  "next",  "#".  "  ".  "3". 

"next",  "c".  "  ".  "fac".  "next".  "  ".  "alpha",  "root"]}. 
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APPENDIX  D:   Transcript  of  fi  Session 

The  following  is  a  transcript  of  an  Q  session  illustrating  the  operation  of  the  prototype  universal  syntax 
directed  editor  and  utilities  presented  in  Appendices  A  and  B,  operating  on  the  sample  transaction  gram- 
mar of  Appendix  C.  The  assertion  'Script  {test_script}'  causes  the  commands  in  testscript  to  be  executed 
in  order.  Each  command  is  printed  on  a  separate  line,  followed  by  whatever  output  is  generated  by  the 
programming  environment.    This  transcript  was  produced  by  the  Mc Arthur  interpreter  (McArthur84). 

%  omega 

OMEGA-1     11/30/84 

Use  Cntl-D  or  exit{}  to  quit. 

For  help,  enter  help{"?"}. 

To  report  a  bug.  enter  Bugs{}. 

newrelation  rule  activated. 

doit/redo  activated:  use  doit'  instead  of  do'. 

>  do  {"PI6.USDE"}. 
Universal  SDE  loaded. 
OK 

>  do  {"PI6.util"}. 

PI— 6  Utilities  activated. 
OK 

>  do  {"PI6.testgram"}. 

program: 

else  (prog)  ->    *:<expr>. 

expr: 

'='  (eql)  ->    left:<arex>  '  =  '  right:<arex>. 
n'  (neq)  ->    left:<arex>  '  <>  '  right:<arex>. 
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else  <arex>  —  >    "  *:<arex>  ". 

arex: 

'+'  (sum)  — >    left:<arex>  '  +  '  right:<term>. 
-    (dif)  ->    left:<arex>  '  -  '  right:<term>. 
else  <term>  — >    "  *:<term>  ". 

term: 

'*'  (prd)  ->  left:<term>  '  x  right:<factor>. 
'/'  (quo)  ->  left:<term>  '  /  '  right: <factor>. 
else  <factor>  — >    "  *:<factor>  *'. 

factor: 

'#'  (con)  ->    litval:<chars> 

c-  (call)  — >    rator:<chars>  '  '  rand:<factor>. 
'('  (par)  — >    '('  exp:<expr>  ')'. 
T  (conex)  — > 
(if  '  cond:<expr> 

then  '  conseq:<expr> 

else  '  alt:<expr>  '  )'. 

I'  (block)  -> 

[let  '  bndvar:<chars>  '  =  '  bndval:<expr> 

T  (fundef)  ->    ' 

[func  '  funname:<chars>  '  '  funformal:<chars>  '  =  '  funbody:<expr> 

else  (var)  — >    ident:<chars>. 

Test  Grammar  loaded. 

OK 

>  Script  {test_script}. 


begin 
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{<«xpr>} 


f 


[func  {<chars>}  <chars>  =  <expr> 
<expr>  J 


fac 

[func  {fac}  <chars>  =  <expr> 
<expr>  J 


next 


[func  fac  {<chars>}  =  <expr> 
<expr>  ] 


n 


[func  fac  {n}  =  <expr> 
<expr>  ] 


next 


[func  fac  n  =  {<expr>} 
<expr>  ] 


[func  fac  n  = 
(if  {<expr>} 
then  <expr> 
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else  <expr>  ) 
<expr>  J 


[func  fac  n  = 

(if  {<arex>}  =  <arex> 

then  <expr> 

else  <expr>  ) 
<expr>  ] 


_n 

[func  fac  n  = 
(if  {<chars>}  =  <arex> 
then  <expr> 
else  <expr>  ) 
<expr>  J 

[func  fac  n  = 
(if  {n}  =  <arex> 

then  <expr> 

else  <expr>  ) 
<expr>  ] 


next 

(if  n  =  {<arex>} 
then  <expr> 
else  <expr>  ) 
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# 

(if  n  =  {<chars>} 
then  <expr> 
else  <expr>  ) 

_0 

(if  n  =  {0} 
then  <expr> 
else  <expr>  ) 

next 

[func  fac  n  = 

(if  n  =  0 
then  {<expr>} 
else  <expr>  ) 

<expr>  ] 

# 

[func  fac  n  = 

(if  n  =  0 
then  {<chars>} 
else  <expr>  ) 

<expr>  ] 


[func  fac  n  = 
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(if  n  =  0 
then  {1} 
else  <expr>  ) 
<expr>  ] 

next 

[func  fac  n  = 
(if  n  =  0 
then  1 

else  {<expr>}  ) 
<expr>  ] 


[func  fac  n  = 
(if  n  =  0 
then  1 

else  {<term>}  x  <factor>  ] 
<expr>  ] 

n 

[func  fac  n  = 
(if  n  =  0 

then  1 

else  {<chars>}  x  <factor> 
<expr>  ] 

[func  fac  n  = 
(if  n  =  0 
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then  1 

else  {n}  x  <factor>  ) 

<expr>  ] 

next 

(if  n  =  0 
then  1 
else  n  x  {<factor>}  ) 


(if  n  =  0 
then  1 
else  n  x  {<chars>}  <factor>  ) 


_fac 

(if  n  =  0 
then  1 
else  n  x  {fac}  <factor> 


next 
n  x  fac  {<factor>} 


n  x  fac  {<chars>} 
n  x  fac  {<factor>} 
Illegal  Key:  - 
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n  x  fac  ({<expr>}) 


n  x  fac  ({<arex>}  -  <term>] 


n 

n  x  fac  ({<chars>}  -  <term>] 
n  x  fac  ({n}  -  <term>) 


next 

(n  -  {<term>}) 

# 
(n  -  {<chars>}) 

_1 

(n-{l}) 

next 

[func  fac  n  = 
(if  n  =  0 
then  1 

else  n  x  fac  (...)  ) 
{<expr>}  ] 


[func  fac  n  = 
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(if  n  =  0 
then  1 
else  n  x  fac  (...)  ) 

[let  {<chars>}  =  <expr> 
<expr>  ] 


_alpha 

[func  fac  n  = 
(if  n  =  0 
then  1 
else  n  x  fac  (...)  ) 

[let  {alpha}  =  <expr> 
<expr>  ] 


next 

[func  fac  n  = 
(if  n  =  0 
then  1 
else  n  x  fac  (...  —  ...)  ) 

[let  alpha  =  {<expr>} 
<expr>  J 


[func  fac  n  = 

(if  n  =  0 
then  1 


-64- 


efee  nx  fac  (...  -  ...)  ) 

|jlW  alpha  =  {<term>}  x  <factor> 
<expr>  ]  ] 


[func  fac  n  = 
(if  n  =  0 
then  1 
else  n  x  fac  (...  -  ...)  ) 

[let  alpha  =  {<chars>}  x  <factor> 
<expr>  ]  ] 


_512 

[func  fac  n  = 
(if  n  =  0 

then  1 

else  n  x  fac  ( ...  -  ...)  ) 

[let  alpha  =  {512}  x  <factor> 
<expr>  ] 


next 


[let  alpha  =  512  x  {<factor>} 
<expr>  ] 


# 
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[let  alpha  =  512  x  {<chars>} 
<  expr>  ] 


_3 

[let  alpha  =  512  x  {3} 
<expr>  | 


next 

[func  fac  n  = 

(if  n  =  0 

then  1 

else  n  x  fac  (...  —  ...) 

[let  alpha  =  512  x  3 
{<expr>}  J] 


[func  fac  n  = 

(if  n  =  0 
then  1 
else  n  x  fac  (...  —  ...)  ) 

[let  alpha  =  512  x  3 
{<chars>}  <factor>  ] 

fac 

[func  fac  n  = 
(if  r»  =  0 


-66- 


then  1 

else  n  x  fac  (...  -  ...)  ) 

[let  alpha  =  512  x  3 
{fac}  < factor >  ] 


next 


[let  alpha  =  512  x  3 
fac  {<factor>}  J 


alpha 

[let  alpha  =  512x3 
fac  {< chars >}  ] 

[let  alpha  =  512  x  3 
fac  {alpha}  ] 


root 

{ 

[func  fac  n  = 

(if  n  =  0 

then  1 

else  n  x  fac  (...)  ) 

[let  alpha  =  512  x  3 

fac  alpha  ]  ]} 

Done 

>  "DepthLimit(5).  DepthLimit(20). 

20 
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>  Command  {"display"}. 

{ 

[func  fac  n  = 

(if  n  =  0 
then  1 
else  n  x  fac  (n  -  1)  ) 

[let  alpha  =  512  x  3 

fac  alpha  ]  ]} 

OK 

>  exit  {}. 

Goodbye. 
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